Hi @ghent360
Thanks for the PR.
I guess it solve issue with Marlin FW ?

Is there a way to check if usb/cdc is connected?

Yeah, this is a complex issue. I added checking the DTR line value, which gets set when the terminal is open and reset when the terminal is closed.

That makes it work almost all the time. Now the edge case is when the terminal is open, but the program on the PC does not actually read the serial data, then it locks again.

In my Ubuntu I use minicom for serial port communication, when I try to exit, there is a confirmation dialog "Are you sure you want to exit", if I stay there long enough the STM32 lock again. If I exit quickly there is no issue, the DTR line is reset and the code stops sending data, but if I linger on the exit dialog, apparently minicom stops reading data from the virtual terminal, but the terminal port is not closed.

What a bummer :-(

This last variant works even if I linger in the minicom menus.
I added a simple timeout if our transmit packet drags for too long I would assume the host is not active.

If people can test this change with different boards and host environments. Look for this #444 (comment) for an example test sketch.
You would need a board with physical serial port as well as USB connector.

I'm going on vacation tomorrow. I'll continue working on this PR when I come back at the end of the week.
Thank you all for the feedback.

@ghent360

I've tried the changes in this PR and this resolves the issue I had with Marlin where the firmware would hang until the serial port is opened on the host side.

On a side note, do you think there is any way that we could have a "serial disconnected" event that we could use within marlin to reset the board if the CDC port is closed/disconnected?

Thanks!

why the serial assistant on PC can't receive data with follow sketch:

#include <Arduino.h>
#include "USBSerial.h"

void setup()
{
    SerialUSB.begin();
    pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
//    if (SerialUSB.available() > 0)
    {
       SerialUSB.println("testing read and wirte");
    }
    digitalToggle(LED_BUILTIN);
    delay(300);
}

Only when I add this line "if (SerialUSB.available() > 0)", then send some data with serial assistant on PC, the PC can receive data continusly.

@roc2 this is not clear. Which board? Core version (1.5.0, master,...)? With this PR applied or not?....

@fpistm My board is Black F407VE, core version 1.5.0.

As it is done in Arduino for the Due.
https://www.arduino.cc/reference/en/language/functions/communication/serial/ifserial/
Try to add in the setup after SerialUSB.begin();

  while (!SerialUSB) {
    ; // wait for serial port to connect. Needed for native USB
  }

@fpistm Add this 'while (!SerialUSB)', it's no working. I have tested with FS and HS mode, the sketch here work fine with FS mode(select the USB speed Low/full speed), but it is not work well with HS mode(I added the USB3300 module on the ULPI interface)

@fpistm Are there any more changes required for this PR?
I believe I addressed add requests, but the thing still shows red.

Currently not. I only need to review it and test deeply.

@ghent360 I've made several test on several boards with different STM32 families and host OS.
It's ok.
Still my comments to discuss.

Thanks @ghent360

Using your sketch #444 (comment)
Works fine under Linux.
Under Windows, Unable to recognized the device after unplug/plug. Enum failed.
Anyway this is better than before :)

Under Windows, Unable to recognized the device after unplug/plug. Enum failed.

Update:
Doing further investigations, if I didn't open a terminal on the COM port. Enumeration is correct each time.

Does my change affect the enumeration?

No @ghent360 , this is better with this PR.
Seems more like a driver issue but only after the COM has been used by Windows host (with a term).

Trying Teraterm, if I well disconnect, then it's ok. This seems very linked to the driver and how Windows handle the COM...